Professional Website Performance: Optimizing the Front End and the Back End by Peter Smith

Author:Peter Smith
Language: eng
Format: mobi, epub, pdf
Published: 0101-01-01T00:00:00+00:00

Tuning InnoDB ❘ 219

MEMORY ALLOCATION IMPLEMENTATIONS

In Linux, the default C library is glibc, which uses ptmalloc2 (itself an

enhancement of dlmalloc — the pt stands for per-thread) for memory allocation.

Numerous alternatives exist, and although they were often written with Linux in

mind, they mostly work across Windows and UNIX, too.

➤

TCMalloc (thread-cache malloc) is Google’s implementation. It claims to be

much faster than ptmalloc, while also reducing lock contention (a problem

under multicore machines) via the use of spin locks. Despite this, it tends to

use more memory than the likes of ptmalloc2.

➤

JEMalloc (named after Jason Evans, the author) is used on Facebook and in

Firefox. It is also the default malloc under FreeBSD. Implementations are

available for OS X, Solaris, and Windows; and performance is considered

similar to that of TCMalloc.

➤

Nedmalloc claims to be faster than any other malloc implementation and is

primarily targeted at Windows; although it will happily run on most UNIX

derivatives, too.

Memory allocation isn’t just about InnoDB, or even MySQL, and is one of the most

under-appreciated aspects of system performance in general. Switching to an alter-

native malloc implementation is painless, can be done on a per-application basis,

and usually results in a signifi cant performance improvement.

Threading

InnoDB makes extensive use of the threading capabilities of the underlying operating system, allowing it to scale well on multicore systems. Some threads are used to service user requests, whereas others run in the background to perform housekeeping. The maximum number of threads used can

be raised and lowered, and there are both advantages and disadvantages to this.

In the past, it was often necessary to limit the number of concurrent threads because the high levels of context switching would eat away at performance. However, increases in the scalability of both operating systems and InnoDB on multicore architectures have decreased this need, and InnoDB generally runs fi ne with no limit on the number of concurrent threads. Should you want to set a limit, however, it is controlled by innodb_thread_concurrency, the default being zero (no limit).

Disk I/O

Given that disk IO is the major bottleneck in many systems, it’s not surprising that the InnoDB developers have devoted considerable time to optimizing performance in this area. When you learn more about threading in the later section, “Background Threads,” you’ll see how fl ushing dirty pages (that is, pages of memory that have been modifi ed and must be written back to disk) can cause spikes in disk activity, and you’ll discover the ways in which InnoDB attempts to solve this. But, for the moment let’s concentrate on the most signifi cant feature of disk I/O handling — the read-ahead mechanism.

c08.indd 219

05/11/12 4:50 PM

220 ❘ CHAPTER 8 TUNING MYSQL

read-ahead Requests

read-ahead requests involve prefetching data from disk if usage patterns suggest that it may soon be needed. In InnoDB, memory pages are grouped in extents, where an extent consists of 64 consecutive pages. If more than a certain number of pages from an extent exists in the buffer cache, MySQL preloads the remaining pages in the extent.

In the past, InnoDB supported two methods of read-ahead:

➤

Random read-ahead — Here,

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.